Why add labels instead of just using the DTS nodelabel?

Why add labels instead of just using the DTS nodelabel?

That is the alternate option, but:

1. There is currently no devicetree API to go from node to nodelabel.
2. Memory region names are typically UPPER_CASE, whereas node labels are lower_case.
3. Adding a label to all of these nodes is much less likely to be disruptive to other users than changing the nodelabel. A search on DT_NODELABEL(sram shows 36 hits already.

Actually I think the biggest problem is from https://docs.zephyrproject.org/latest/guides/dts/intro.html#syntax-and-structure

A node can have zero, one, or multiple node labels.

Actually I think the biggest problem is from https://docs.zephyrproject.org/latest/guides/dts/intro.html#syntax-and-structure

A node can have zero, one, or multiple node labels.

Is it?
Just like you're adding label prop, we can make sure that there is one label.
Then, I don't think having multiple node labels is an issue in our case.
Also, a major advantage for node labels being that they are unique, 2 nodes can't have same node label (checked by dts).

I am happy to transition to generating from the node labels if that is the generally preferred solution.
The remaining question is whether lower case region names are acceptable, or do they need to be upper-cased.

I am happy to transition to generating from the node labels if that is the generally preferred solution.

Thanks. I think that would indeed be preferred as in general we've tried to minimize their usage over the past years.

The remaining question is whether lower case region names are acceptable, or do they need to be upper-cased.

No preference on my part.
Maybe some have strong opinions on that though..

Are you aware of any syntax that lets you change or add another nodelabel to a node in an overlay? Apart from just deleting the node and creating it again?

Are you aware of any syntax that lets you change or add another nodelabel to a node in an overlay? Apart from just deleting the node and creating it again?

new_nodelabel: &existing_nodelabel {};

new_nodelabel: &existing_nodelabel {};

Cheers. Interestingly it looks like doing this in overlays always results in new_nodelabel being after existing_nodelabel in node.lables in python. Assuming that the solution will just use index 0 to generate a region name, it won't be possible to change the name in an overlay without changing some edtlib parsing.

Cheers. Interestingly it looks like doing this in overlays always results in new_nodelabel being after existing_nodelabel in node.lables in python. Assuming that the solution will just use index 0 to generate a region name, it won't be possible to change the name in an overlay without changing some edtlib parsing.

@mbolivar-nordic Is that expected ?

An overlay of

test1: &sram0 {};
test2: &sram0 {};

Will result in a zephyr.dts of

	sram0: test1: test2: memory@24000000 {

So it makes sense that the python labels have the order they do.
I feel like overlays should be able to override the name of the memory region, so I will look into the easiest way of just selecting the last property in a list.

Superseded by #36365

I haven't been following the discussion, but arbitrarily picking a node label as a canonical way to identify a node does not sound like a good approach. I will check #36365.